Changes look good, the strings that were temporarily in the pending.ftl files have been merged in the l10n repo.

(suggestion, non-blocking) The instructions on README for pending strings only mentions:

If you're not yet ready to submit some strings for translation, you can tentatively add them to frontend/pendingTranslations.ftl. Strings in that file will show up until strings with the same ID are added to the l10n repository.

Should we add another line in README and on pending.ftl indicating pending strings should be removed after string is merged in the l10n repo?

Yes, this will be a good addition. I recall this same issue happened before because pending strings were kept. Do you want me to add that change in this PR?

(comment) Interesting to note that the frontend/pendingTranslations.ftl still has old strings that are merged but does not error. I wonder if there is a configuration to use the l10n repo strings if the string is found in both pending and in translations repo.

@rafeerahman, adding the comments in this PR would be helpful.

(comment) Interesting to note that the frontend/pendingTranslations.ftl still has old strings that are merged but does not error. I wonder if there is a configuration to use the l10n repo strings if the string is found in both pending and in translations repo.

Yeah, the issue seems to be in https://github.com/mozilla/fx-private-relay/blob/main/privaterelay/ftl_bundles.py#L29-L40, where Bundle() causes an error if there are duplicate strings from the files listed. Would be nice if we could have a configuration to ignore/fix this.

(comment) Interesting to note that the frontend/pendingTranslations.ftl still has old strings that are merged but does not error. I wonder if there is a configuration to use the l10n repo strings if the string is found in both pending and in translations repo.

Yep, the frontend only uses the pending strings if the IDs aren't found among the l10n repo's strings, but otherwise ignores them - i.e. they're a fallback only.